今天講整套流程裡投報率最高的一步。

如果 Part 2 你只做一件事，我建議是這件：準備兩三個修到完美的黃金範例。

理由是 Day 13 提過的那個觀察，今天完整展開。

一個違反直覺的事實

AI 模仿範例的能力，遠遠大於它遵守文字規則的能力。

我們的直覺是相反的：規則比較嚴謹，範例比較隨便。

規則是明確的、可窮舉的、可逐條檢查的。範例只是「某一個實例」，充滿了跟這次任務無關的細節。

所以要讓 AI 產出符合規範的程式，直覺做法是把規範寫清楚。

實際上不是這樣。

你寫十條規則——命名怎麼取、錯誤怎麼包、資料存取不可以出現在控制器、非同步方法要加什麼後綴。AI 會遵守其中大部分，然後在某個你沒特別強調的地方漏掉。而且每次漏的地方不一樣。

但你給它兩個寫得很好的既有檔案，說「照這個樣子寫」。它模仿出來的東西，在一致性上會明顯勝過照規則寫的。

而且更有意思的是：**它會模仿到你沒寫進規則裡的東西。**註解的密度、參數的排列習慣、前置檢查放在哪、測試方法命名的節奏。這些你很難寫成規則（寫出來會變成一百條），但範例裡全部都有，而 AI 會一起接收。

我後來把它總結成一句：

規則傳遞的是「不可以做什麼」，
範例傳遞的是「該長什麼樣」。
而大部分的品質問題，出在後者。

回頭看 Day 08 那個案子

現在可以解釋一件事了。

Day 08 那個遷移案，AI 在每一支控制器裡包 try-catch、把讀寫混在同一個服務、手寫 DTO 映射。架構合規度 60%。當時我的說法是「AI 用先驗補空白」。今天可以講得更精確：因為它沒有東西可以模仿，所以它模仿了訓練資料裡的東西。

網路上九成的 .NET 教學就是那樣寫的。AI 不是在違反規範，它是在遵守它唯一知道的範本。

而那個案子的規範是文字的。「統一由基底控制器處理例外」。文字對抗不了範本。

要對抗一個範本，你得給它另一個範本。

那個案子後來的品質報告，根本原因寫的正好是這句話：

缺乏統一的程式碼範本與規範。

注意順序：範本在前，規範在後。

範例品質是產出品質的上限

薪資工廠的做法是這樣的：

.ai/tech-stacks/{技術棧}/examples/
    payroll-rule/    ← 黃金範例：一條薪資計算規則
    use-case/        ← 黃金範例：一個業務流程

只有兩個範例。

不是二十個，是兩個。因為它們要被修到完美。

我在流程裡寫了一句話，我認為是整套方法最重要的一條：

範例品質 = 產出品質的上限。

AI 產出的東西，不會比你給它的範例更好。

所以「跟使用者一起把範例人工 review 到完美」是一個明確的步驟，不是可選項。這一步通常花掉半天到一天，而且很多團隊想跳過。因為感覺是在做沒有產出的事。

但你可以這樣算：這半天決定了接下來三十個功能的品質天花板。

它是整套流程裡槓桿最大的半天。

一個沒預料到的副作用

修範例的過程中，發生了一件我沒想到的事：

團隊被迫把一堆長期沒有共識的爭議吵完了。

錯誤要不要包一層？DTO 放哪？測試要不要用參數化？金額用什麼型別？捨入規則怎麼寫？這些爭議平常會在每一次 code review 重來一次，每次都吵、每次都沒有結論、每次都各自照自己的習慣寫。現在一次解決，而且解決的結果被固定在一個看得到的檔案裡。

之後有人想改？可以，但你要去改那個範例，而且要說服大家。爭議從「每次都吵」變成「改一次範例」。

每個範例配一份說明

光給範例還不夠，因為 AI 不知道這個範例哪些部分是重點、哪些只是這次的業務細節。

所以每個範例旁邊放一份說明檔，條列「這個範例示範了什麼」：

# 薪資計算規則 — 範例說明

這個範例示範了：

- **分層歸屬**：規則只做計算，不碰資料存取
- **級距查表**：一律走級距表，禁止用核定薪資直接乘費率
- **捨入規則**：全式捨入，且捨入點在最後（見決策紀錄 ADR-0005）
- **測試寫法**：每一條後置條件對應一個測試，邊界值另外列
- **不要模仿的部分**：第 88–95 行的相容處理是為了舊資料，新規則不需要

最後那一條「不要模仿的部分」是我後來加的，因為踩過。範例是真實的程式碼，而真實的程式碼一定會有為了歷史原因存在的東西。如果你不明講，AI 會把那段相容處理一起模仿到每一條新規則裡。

規範要從範例反推

Phase 1 的最後一步是寫編碼規範。這裡有一個做法上的關鍵：

規則要從黃金範例反推，不是憑空寫。

差別在哪？

憑空寫：坐下來想「我們的編碼規範應該有哪些」，然後列出二十條你在別的地方看過的好習慣。反推：打開那兩個範例，逐項記錄「它實際上是怎麼做的」，然後把它寫成規則。反推出來的規則有三個好處：

1. 它一定是這個專案真的在用的，不是理想中的
2. 每一條都可以附上範例的行號當佐證——規則不是「我覺得」，是「你看第 47 行」
3. 它不會有做不到的條目，因為範例本身就是活的證明

而規範的三塊內容裡，有一塊特別重要：

禁用清單——禁止使用的 API、註記、寫法。

因為它是明天那支結構檢查腳本可以直接 grep 的東西。

能被 grep 的規則，就不用靠 AI 記得。

這句話是第 0 層和第 3 層之間的橋。你在寫規範的時候多想一句「這條能不能 grep」，就能把一堆規則直接推上第 3 層。

小結

• AI 模仿範例 >> 遵守規則，而且會模仿到你沒寫進規則的東西
• 要對抗一個範本，得給它另一個範本——這是 Day 08 那個案子真正缺的東西
• 範例品質是產出品質的上限，所以「修到完美」是必要步驟不是可選項
• 每個範例配一份說明，包括「不要模仿的部分」
• 規範從範例反推，而且刻意寫出「能被 grep」的禁用清單

明天講那三支腳本，包括我原本以為最難寫、後來發現最有價值的那一支。